home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 16925 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  2.8 KB
  1. Path: keats.ugrad.cs.ubc.ca!not-for-mail
  2. From: c2a192@ugrad.cs.ubc.ca (Kazimir Kylheku)
  3. Newsgroups: comp.lang.c++,comp.lang.c,comp.os.ms-windows.programmer.misc
  4. Subject: Re: fastest code
  5. Date: 12 Apr 1996 11:19:19 -0700
  6. Organization: Computer Science, University of B.C., Vancouver, B.C., Canada
  7. Message-ID: <4km6r7INNst8@keats.ugrad.cs.ubc.ca>
  8. References: <316112A2.7D37@public.sta.net.cn> <4kgu7g$n9a@solutions.solon.com> <4kjc9n$f7j@samba.rahul.net> <316E1037.41C67EA6@scn.de>
  9. NNTP-Posting-Host: keats.ugrad.cs.ubc.ca
  10.  
  11. In article <316E1037.41C67EA6@scn.de>,
  12. Gerolf Wendland  <wendland%hpp015%hpp001.mch2.scn.de@scn.de> wrote:
  13. >Whoever started this, he wrote:
  14. >> 
  15. >> >>: >>           for (i=0; i<16; i++)
  16. >> >>: >>                   prom[i] = prom[i+i];
  17. >> >
  18. >> >>: HUH?  the code as written has a clear effect, which is to shove all of
  19. >> >>: the elements of an array over one.  It certainly is an optimizer bug.
  20. >                                                             ^^^^^^^^^^^^^^
  21. >Really?
  22. >
  23. >Richard Krehbiel:
  24. >>In fact, I wrote exactly this loop once whose purpose was to initialize the
  25. >>parity bits in memory, but be non-destructive in case it was just a
  26. >>restart and not a power-on.
  27. >
  28. >This seems to indicate that prom[i] are assigned a values that are never used.
  29. >Maybe the optimizer has seen this. It should have issued a warning, which (the
  30. >issueing) may have been prevented by not prom being the variable but by the 
  31. >somewhat anonymous locations prom[i] being the variables in question. The optimizer 
  32. >would have been even better if it had seen the fact that the loop is superflouos 
  33. >and had removed it as well.
  34. >
  35. >The volatile keyword is surely a good way to circumvent this problem.
  36.  
  37. It may be and it may not be. Using keywords isn't going to fix a bug in the
  38. compiler, though it may work around it.
  39.  
  40. As I stated earlier, I looked into the actual device driver, and the values
  41. _are_ used. Also a complete example program was shown here which prints the
  42. values of the array, as an example of clear afterward use. It failed to compile
  43. properly. The printing loop produced the original values, not the transformed
  44. array you expect.
  45.  
  46. The volatile keyword should have no effect on this with a correctly functioning
  47. compiler. Suppose that the assignments to prom[] were optimized away into
  48. a register file, or some internal cache on the CPU (this is not too far
  49. fetched---a DSP compiler might quite well do this). A subsequent use of the
  50. array would still show the correct answer, regardless of the underlying code
  51. sequence.
  52.  
  53. The keyword should not change the value produced by a program when used in
  54. conjunction of a variable that is not truly volatile. prom[] is not a memory
  55. mapped hardware port, it's not a global variable accessed by signal handlers,
  56. and the function in which it is used does not use setjmp/longjmp.
  57. -- 
  58.  
  59.